<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="description" content="">
    <meta name="author" content="">
    <meta name="keyword" content="">
    <link rel="shortcut icon" href="/node-mongodb-native/img/favicon.png">

    <title>Sharding</title>

    <link href="/node-mongodb-native/css/bootstrap-theme.css" rel="stylesheet">
    <link href="/node-mongodb-native/assets/font-awesome/css/font-awesome.min.css" rel="stylesheet" />
    <link href="/node-mongodb-native/css/style.css" rel="stylesheet">
    <link href="/node-mongodb-native/css/style-responsive.css" rel="stylesheet" />
    <link href="/node-mongodb-native/css/monokai_sublime.css" rel="stylesheet" />

  </head>

  <body>

  <section id="container" class="">


      <header class="header black-bg">
            <div class="toggle-nav">
                <i class="fa fa-bars"></i>
                <div class="icon-reorder tooltips" data-original-title="Toggle Navigation" data-placement="bottom"></div>
            </div>


            <a href="/node-mongodb-native/" class="logo"><img src="/node-mongodb-native/img/logo-mongodb-header.png" style="height:40px;"></a>

            <div class="nav title-row" id="top_menu">
                <h1 class="nav top-menu"> Sharding </h1>
            </div>
      </header>



<aside>
    <div id="sidebar"  class="nav-collapse ">

        <ul class="sidebar-menu">




            <li class="sub-menu active">
            <a href="javascript:;" class="">
                <i class='fa fa-book'></i>

                <span>schema design</span>
                <span class="menu-arrow fa fa-angle-down"></span>
            </a>
                <ul class="sub open">

                    <li><a href="/node-mongodb-native/schema/chapter1/"> Introduction </a> </li>

                    <li><a href="/node-mongodb-native/schema/chapter2/"> Schema Basics </a> </li>

                    <li><a href="/node-mongodb-native/schema/chapter3/"> MongoDB Storage </a> </li>

                    <li><a href="/node-mongodb-native/schema/chapter4/"> Indexes </a> </li>

                    <li><a href="/node-mongodb-native/schema/chapter5/"> Metadata </a> </li>

                    <li><a href="/node-mongodb-native/schema/chapter6/"> Time Series </a> </li>

                    <li><a href="/node-mongodb-native/schema/chapter7/"> Queues </a> </li>

                    <li><a href="/node-mongodb-native/schema/chapter8/"> Nested Categories </a> </li>

                    <li><a href="/node-mongodb-native/schema/chapter9/"> Account Transactions </a> </li>

                    <li><a href="/node-mongodb-native/schema/chapter10/"> Shopping Cart </a> </li>

                    <li class="active"><a href="/node-mongodb-native/schema/chapter11/"> Sharding </a> </li>

                </ul>

              </li>


                <li>
                <a class="" href="https://mongodb.github.io/node-mongodb-native/2.2">
                    <i class='fa fa-file-text'></i>

                    <span>2.0 driver docs</span>
                </a>

              </li>


                <li>
                <a class="" href="https://mongodb.github.io/node-mongodb-native/2.2">
                    <i class='fa fa-file-text'></i>

                    <span>1.4 driver docs</span>
                </a>

              </li>


                <li>
                <a class="" href="https://mongodb.github.io/node-mongodb-native/2.2">
                    <i class='fa fa-file-text'></i>

                    <span>Core driver docs</span>
                </a>

              </li>

            <li> <a href="https://groups.google.com/forum/#!forum/learn-mongo-db-the-hardway" target="blank"><i class='fa fa-life-ring'></i>Issues & Help</a> </li>


        </ul>

    </div>
</aside>




      <section id="main-content">
          <section class="wrapper">













              <div class="row">
                  <div class="col-md-1">


                      <a class="navigation prev" href="/schema/chapter10">
                      <i class="fa fa-angle-left"></i>
                      </a>


                  </div>
                <div class="col-md-10">
                    <section class="panel">



                    <div class="panel-body">



<h1 id="sharding:783a13680e5de96acfee68995945d897">Sharding</h1>

<p>Sharding is one of those mystical aspects of MongoDB that it take awhile to wrap ones head around. Basically sharding is a mechanism by which one can scale writes by distributing the writing to multiple primaries (shards). Each document has a shard key associated with it which decides on what primary the document lives.</p>

<h2 id="sharding-topology:783a13680e5de96acfee68995945d897">Sharding Topology</h2>

<p>In MongoDB sharding happens at the <strong>collection</strong> level. That is to say that you can have a combination of sharded and unsharded collections. Let&rsquo;s look at a simple topology.</p>

<p><img src="/images/originals/sharded.png" alt="Simple Two Shard Topology" />
</p>

<p>The application talks to the <strong>Mongos</strong> proxies to write to the sharded system.</p>

<h2 id="when-to-shard:783a13680e5de96acfee68995945d897">When to Shard</h2>

<p>One of the typical errors is to shard to early. The reason this can be a problem is that sharding requires the developer to pick a shard key for distribution of the writes and one can easily pick the wrong key early due to not knowing how the data needs to be accessed. This can cause reads to be inefficiently spread out causing unnecessary <strong>IO</strong> and <strong>CPU</strong> usage to retrieve the data. Once the collection is sharded with a key it can be very time consuming to undo it as all the data will have to migrated from one sharded collection to another rewriting the all the documents.</p>

<p>Let&rsquo;s look at some reason you might want to Shard.</p>

<ol>
<li><p>Your Working Set no longer fits in the memory of you computer. Sharding can help more of your Working Set to be in memory by pooling the RAM of all the shards. Thus if you have a 20GB Working Set on a 16GB machine, sharding can split this across 2 machines or 32GB instead, keeping all of the data in RAM.</p></li>

<li><p>Scaling the write IO. You need to perform more write operations than what a single server can handle. By Sharding you can balance out the writes across multiple computers, scaling the total write throughput.</p></li>
</ol>

<h2 id="choosing-a-shard-key:783a13680e5de96acfee68995945d897">Choosing a Shard Key</h2>

<p>It&rsquo;s important to pick a Shard key based on the actual read/write profile of your application to avoid inefficiencies in the application. That said there are a couple of tips that can help finding the right shard key.</p>

<h3 id="easily-divisible-shard-key:783a13680e5de96acfee68995945d897">Easily Divisible Shard Key</h3>

<p>If the picked shard key is easily divisible it makes it easier for MongoDB to distribute the content among the shards. If a key has a very limited number of possible values it can lead to inefficient distribution of the documents causing an uneven amount of reads and writes to go to a small set of the shards.</p>

<h3 id="high-randomness-shard-key:783a13680e5de96acfee68995945d897">High Randomness Shard Key</h3>

<p>A key with high randomness will evenly distribute the writes and reads across all the shards. This works great if documents are self contained entities such as Users. However queries for ranges of document such as all users with age less than 35 years will require a scatter gather.</p>

<h3 id="single-shard-targeted-key:783a13680e5de96acfee68995945d897">Single Shard Targeted Key</h3>

<p>Picking a shard key that groups the documents together will make most of the queries go to a specific Shard, meaning one can avoid scatter gather queries. One possible example might be a geo application for the UK where the first part of the key includes the postcode and the second is the address. Due to the first part of the shard key being the postcode all documents for that particular sort key will end up on the same Shard, meaning all queries for a specific postcode will be routed to a single Shard.</p>

<p>The UK postcode works as it has a lot of possible values due to the resolution of postcodes in the UK. This means there will only be limited amount of documents in each chunk for a specific postcode. However if we where to do this for a US postcode we might find that each postcode includes a lot of addresses causing the chunks to be hard to split into new ranges. The effect is that MongoDB is less able to spread out the documents and it thus impacts performance.</p>

<h2 id="routing-shard-keys:783a13680e5de96acfee68995945d897">Routing Shard Keys</h2>

<p>Depending on your Shard key the routing will work differently. This is important to keep in mind as it will impact performance.</p>

<table>
<thead>
<tr>
<th>Type Of Operation</th>
<th>Query Topology</th>
</tr>
</thead>

<tbody>
<tr>
<td>Insert</td>
<td>Must have the Shard key</td>
</tr>

<tr>
<td>Update</td>
<td>Can have the Shard key</td>
</tr>

<tr>
<td>Query with Shard Key</td>
<td>Routed to nodes</td>
</tr>

<tr>
<td>Query without Shard Key</td>
<td>Scatter gather</td>
</tr>

<tr>
<td>Indexed/Sorted Query with Shard Key</td>
<td>Routed in order</td>
</tr>

<tr>
<td>Indexed/Sorted Query without Shard Key</td>
<td>Distributed sort merge</td>
</tr>
</tbody>
</table>

<h2 id="inbox-example:783a13680e5de96acfee68995945d897">Inbox Example</h2>

<p>Imagine a social Inbox. In this case we have two main goals</p>

<ol>
<li>Send new messages to it&rsquo;s recipients efficiently</li>
<li>Read the Inbox efficiently</li>
</ol>

<p>We want to ensure we meet two specific goals. The first one is to write to multiple recipients on separate shards thus leveraging the write scalability. However for a user to read their email box, one wants to read from a single shard avoid scatter/gather queries.</p>

<p><img src="/images/originals/sharded_inbox_write.png" alt="Fan out write, Single shard Read" />
</p>

<p>How does one go about getting the correct shard key. Let&rsquo;s assume we have two collections <strong>inbox</strong> and <strong>users</strong> in our <strong>social</strong> database. Let&rsquo;s do the collection sharding.</p>

<pre><code class="language-js">var db = db.getSisterDB('social');
db.shardCollection('social.inbox', {owner: 1, sequence: 1});
db.shardCollection('social.users', {user_name: 1});
</code></pre>

<p>Let&rsquo;s write and read to the collections with some test data to show how we can leverage the sharding.</p>

<pre><code class="language-js">var db = db.getSisterDB('social');
var msg = {
  from: 'Christian',
  to: ['Peter', 'Paul'],
  sent_on: new Date(),
  message: 'Hello world'
}

for(var i = 0; i &lt; msg.to.length; i++) {
  var result = db.users.findAndModify({
    query: { user_name: msg.to[i] },
    update: { '$inc': {msg_count: 1} },
    upsert: true,
    new: true
  })

  var count = result.msg_count;
  var sequence_number = Math.floor(count/50);
  db.inbox.update({ owner: msg.to[i], sequence: sequence} ),
    { $push: {messages: msg} },
    { upsert:true });
}

db.inbox.find({owner: 'Peter'})
  .sort({sequence: -1})
  .limit(2);
</code></pre>

<p>The first part delivers the message to all it&rsquo;s recipients. First it updates the message count for the recipient and then pushes the message to the recipients mailbox (which is a embedded document). The combination of the Shard key being <strong>{owner: 1, sequence: 1}</strong> means that all new messages get written to the same chunk for an owner. The <strong>Math.floor(count/50)</strong> generation will split up the inbox into buckets of 50 messages in each.</p>

<p>This last aspect means that the read will route by owner directly to a single chunk on a single Shard avoiding scatter/gather and speeding up retrieval.</p>

<h2 id="multiple-identities-example:783a13680e5de96acfee68995945d897">Multiple Identities Example</h2>

<p>What if we need to lookup documents by multiple different identities like a username or an email address.</p>

<p>Take the following document.</p>

<pre><code class="language-json">var db = db.getSisterDB('users');
db.users.insert({
  _id: 'peter',
  email: 'peter@example.com'
})
</code></pre>

<p>If we shard by <strong>_id</strong> it means that only <strong>_id</strong> queries will be routed directly to the right shard. If we wish to query by email we have to perform a scatter/gather query.</p>

<p>There is a possible solution called document per identity. Let&rsquo;s look at a different way of representing the information.</p>

<pre><code class="language-js">var db = db.getSisterDB('users');

db.identities.ensureIndex({ identifier: 1 }, { unique: true });

db.identities.insert({
  identifier: {user: 'peter'}, id: 'peter'});

db.identities.insert({
  identifier: {email: 'peter@example.com', user: 'peter'},
  id: 'peter'});

db.shardCollection('users.identities', {identifier: 1});
db.users.ensureIndex({ _id: 1}, { unique: true });
db.shardCollection('users.users'. { _id: 1});
</code></pre>

<p>We create a unique index for the <strong>identities</strong> table to ensure we cannot map two entries into the same identity space. Since identifier is a compound index we can not actually query directly to a shard using this key. So it&rsquo;s still a single read to retrieve a user by <strong>_id</strong> and now we can retrieve a user by it&rsquo;s email by performing two direct queries using the correct identifier. Let&rsquo;s see how to do this for an <strong>email</strong> user lookup.</p>

<pre><code class="language-js">var db = db.getSisterDB('users');

var identity = db.identities.findOne({
  identifier: {
    email: 'peter@example.com'}});

var user = db.users.find({ _id: identity.id });
</code></pre>

<p>The first query locates the identity using the email, which is a routed query to a single shard, and the second query uses the returned <strong>identitiy.id</strong> field to retrieve the user by the shard key.</p>



                <div class="col-md-1">


                    <a class="navigation next" href="/schema/chapter1">
                        <i class="fa fa-angle-right"> </i>
                    </a>


                </div>
              </div>

          </section>
      </section>

  </section>


    <script src="/node-mongodb-native/js/jquery-2.1.1.min.js"></script>
    <script src="/node-mongodb-native/js/jquery.scrollTo.min.js"></script>
    <script src="/node-mongodb-native/js/bootstrap.min.js"></script>

    <script src="/node-mongodb-native/js/highlight.pack.js"></script>
    <script>hljs.initHighlightingOnLoad();</script>
    <script src="/node-mongodb-native/js/scripts.js"></script>
    <script async defer id="github-bjs" src="/node-mongodb-native/js/buttons.js"></script>
    <script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-41953057-1', 'auto');
  ga('send', 'pageview');

</script>
  </body>
</html>
